Evaluating the Design of an Audit Data Anonymizer Using Basic Building Blocks for Anonymity∗

Using an audit data anonymization system as an example, we show how the APES approach for basic anonymity building blocks can be used to evaluate the design of a given anonymity system. As a side-product we obtain indications of the incompleteness of the APES building blocks approach. 1 APES: Anonymity and Privacy in Electronic Services In the APES project (Anonymity and Privacy in Electronic Services) the state-of-the-art of anonymity systems has been surveyed and studied [5]. Anonymity systems for various applications are described: anonymous connections, email, web publishing, web browsing, electronic payments, electronic elections and electronic auctions. For several applications exists more than one anonymity system based on different anonymity techniques. The anonymity techniques themselves are often composed of several subcomponents that are each responsible for a particular anonymity aspect. The anonymity systems have been decomposed into basic building blocks that can be reused for different systems, with a focus on unconditional anonymity, i.e. the anonymity cannot be revoked. The basic building blocks are identified, their properties and requirements are described and their security and correctness are evaluated in an informal way [6]. A more detailed overview of the project is given by Diaz, Claessens and Preneel [7] and in the project deliverables [5, 6, 8]. 1.1 Basic Building Blocks for (Unconditional) Anonymity Anonymity systems are often designed with a specific application in mind. These systems, however, often have similar functionality that can be reused for other applications. As a part of the APES project De Win et al. [6] define reusable anonymity building blocks with minimal, yet useful functionality. This approach has several advantages: ∗This work is currently partially funded by the German Research Council (DFG) under grant number Bi 311/10-2. 1 APES: ANONYMITY AND PRIVACY IN ELECTRONIC SERVICES 2 1. Similar building blocks can be compared more easily than the more complex systems they originate from. 2. Given a list of building blocks with their properties, deficiencies in existing systems can be identified systematically. 3. Anonymity systems can be designed by systematically composing appropriate building blocks. We present the APES anonymity building blocks approach here in more detail to revisit the design of our systems [1, 2] in Sect. 2. We decompose our systems into building blocks with the following goals according to the above advantages: 1. The building blocks used are compared to different building blocks with similar functionality with the two possible results: The systems are already composed of building blocks that are optimal for the given application, or we obtain specific indications how we can improve the systems by replacing some building block with some other building block yielding stronger properties. 2. Given the attacker and trust model of our application we may identify deficiencies of our systems in an informal way by considering all building blocks in the supposedly exhaustive list given by De Win et al. [6]. 3. As a side-product we obtain indications of the completeness of the list and classifications of APES building blocks with respect to our applications. 1.2 Approach APES basic building blocks are classified as being specific to the application-level or the connectionlevel: Connection-level basic building blocks are used to provide anonymous communication connections, whereas application-level basic building blocks are supposedly application-specific. To obtain a completely anonymous system, application-level anonymity often needs to be complemented by connection-level anonymity. For each basic building block the properties are given informally, such that building blocks with similar functionality can be compared. 1.2.1 Connection-level basic building blocks Basic building blocks at the connection-level hide or remove identifying information that is available at that level. Identifying information can occur explicitly like IP-Addresses in IP packet headers or an individual’s name in the body of the packet. Connections can also be traced along the communication path using implicit features of the appearance or of the flow of the communication. Network packets can be linked by appearance using f.i. content, format or size. Also the flow of network packets can be traced using the knowledge about the packet processing regarding f.i. order and timing. Accordingly, 1 APES: ANONYMITY AND PRIVACY IN ELECTRONIC SERVICES 3 APES basic building blocks at the connection-level either change the appearance or the flow. (see the second column of Table 1). To provide anonymous connections, explicitly as well as implicitly identifying information must be hidden. Therefore basic building blocks need to be composed to change the appearance as well as the flow of the messages. The following compositions of basic building blocks to so-called local setups are proposed: serial: Building blocks are executed after each other, where the input of the latter block is the output of the former block. parallel: Functionally unrelated building blocks can be executed in parallel, given that at most one building block changes the appearance of the message. nested: The execution of the outer block is suspended for the execution of the inner block. This may be required for advanced message transformations or block dependencies [6]. A local setup is controlled by one entity of the anonymity system. The single point of trust failure problem may be solved by serially composing an anonymity system, also called a global setup, of several identical local setups which are each controlled by different entities. 1.2.2 Application-level basic building blocks Basic building blocks at the application-level hide or remove identifying information that is available at this level. They implement techniques that have been developed to add anonymity to a particular type of application (see the third column in Table 1). De Win et al. found that most building blocks at this level are no basic building blocks, they rather solve an application-specific anonymity problem by combining several more elementary building blocks, which do not offer anonymity by themselves [6]. These more elementary building blocks have not been described. Also the functionality of the building blocks at this level is rather different, i.e. we cannot choose between several alternative building blocks to achieve a specific functionality. As a result, most building blocks already are complete local setups and can hardly be locally combined with other building blocks. Nevertheless anonymity systems can be composed of building blocks that are used between different entities or during different phases of the application. 1.2.3 Composition strategy For the composition of an anonymity system out of building blocks in APES the following factors need to be considered with respect to: application: anonymity requirements, attacker model, overall application structure building blocks: properties, dependencies, tradeoff of security vs. performance 2 REVISITING AUDIT DATA ANONYMIZATION 4 APES does not provide an algorithm that will compose anonymity systems from building blocks, given the above information as input. Instead in APES a pragmatic approach is used to compose two example applications, starting out with a simple attacker model and sketching the composition of the anonymity system. In each further iteration a slightly stronger attacker is assumed and the composed anonymity system is complemented with building blocks that counter the possible new attacks [8]. 2 Revisiting Audit Data Anonymization Modern services and operating systems hosting them support the recording of audit data for various purposes, f.i. security and billing. Since audit data can usually be used without much effort to identify individual users of a system or of a service [9], recording such data may conflict with the users’ expectancy for privacy and even with pertinent legislation concerning personal data of users. Audit data can be pseudonymized after its generation to avoid the conflict between the desire for security of services and the desire for privacy of users, particularly accountability and anonymity, respectively. We proposed concepts for the pseudonymization of audit data while balancing the conflicting requirements for anonymity and accountability [1]. Accordingly, we provided an implementation of pseudonymization, such that users appear under pseudonyms in Unix audit data, while maintaining the degree of linkability required for audit data analysis [2]. During normal operation only the pseudonymized audit data is analyzed wrt. misuse suspicions. Only upon good cause shown, i.e. a misuse suspicion, the identifying data behind the pseudonyms can be revealed immediately, i.e. accountability can be established. When related to various other work, our approach exhibits several advantages, i.a. technical enforcement of purpose binding, the possibility of immediate reidentification independently of third parties, practicability due to independence of the user system and of expensive infrastructures such as PKI [4]. Using two architectural models for anonymous authorization and surveillance Fig. 1 illustrates the flow of explicitly identifying (solid arrows) or pseudonymized (dashed arrows) information as well as the control conditions (fat grey frames) when a user accesses a service where identifying data in audit records is replaced with pseudonyms after generation [4]. Firstly, a user-side management software selects proper credentials that afford authorization for the desired access. Before access is granted, the credentials are verified wrt. trust, validity, authenticity and the service access policy. The credentials may contain explicitly identifying information about the user (f.i. account name and password or X.509 certificates). Also the communication system may reveal identifying information about the user. In our approach exclusively the identifying information being materialized in the audit data that is generated during the service access is hidden using pseudonymization (see E1 in Fig. 1). Identifying information that is available on the network, during credential verification or during service access is assumed not to be available to attackers that might want to compromise user-identifying data [1, 2]. Since the responsibilities of the site security officer (SSO) include establishing accountability for certain user activities, his interest may conflict with the user interest in anonymity. Therefore the SSO is explicitly precluded from controlling the user’s management component as well as the service, 2 REVISITING AUDIT DATA ANONYMIZATION 5